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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 1 of a multi-part deliverable covering the TIPHON meta-protocol, as identified below: 

Part 1: Meta-protocol design rules, development method, and mapping guideline; 

Part 2: Registration and Service Attachment service meta-protocol definition; 

Pai-t 3: TIPHON Simple Call; 

Part 4: Media control and meta-protocol; 

Part 5: Transport control service meta-protocol definition. 
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Scope 



The present document defines by means of an information model, a functional entity behavioural model, and by 
validated SDL a model of the abstract behaviour of each service and service capability identified as being essential in 
TIPHON R4. 

The present document defines the method of defining a meta-protocol using a worked example for clarification. In 
addition the present document defines the approach to be used to identify the mapping of any candidate protocol to the 
meta-protocol. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI TS 101 314: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Abstract Architecture & Reference Points Definition; Network Architecture 
and Reference Points". 

[2] Void. 

[3] ETSI TR 101 877: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Requirements Definition Study; Scope and Requirements for a Simple call". 

[4] ETSI TS 101 878 V4.1.1: "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON) Release 4; Service Capability Definition; Service Capabilities for a simple 
call". 

[5] Void. 

[6] ETSI TS 102 024-2: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; End-to-end Quality of Service in TIPHON Systems; Part 2: Definition of 
Speech Quality of Service (QoS) Classes". 

[7] ITU-T Recommendation Z. 100: "Specification and Description Language (SDL)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 101 877 [3] and TS 101 878 [4] apply. 



ETSI 



ETSI TS 101 882-1 V4.1.1 (2003-09) 



3.2 Abbreviations 



For the purposes of the present document, the abbreviations defined in TR 101 877 [3] and TS 101 878 [4] and the 
following apply: 

FEA Functional Entities Actions 

OMG Object Management Group 

PDU Protocol Data Units 

PE Protocol Entities 

QFE Qos Functional Entities 

SCN Switched Circuit Network 

SDL Specification and Description Language 

UML Unified Modelling Language 



What is the meta-protocol? 



4.1 Introduction 

The meta-protocol serves as the platform for candidate protocols to map to and in which the mapping identifies exactly 
how the requirements are met. 

The description of the meta-protocol consists of 2 parts: 

• requirements of the service or service capability; and 

• functional behaviour of the service or service capability. 

4.2 Content of the requirements section 

The requirements section of the meta-protocol for any service (or service capability) is an overall description from the 
user's standpoint and consists of a definition and description of the service (or service capability) in prose, followed by 
an overall summary of the dynamic behaviour in either an SDL process diagram, or an UML activity diagram. 

4.2.1 Definition 

This clause provides a short description of the service (or service capability) in terms of the perceptions of the user 
receiving the service (or service capability) and any other users involved in the service (or service capability). 

4.2.2 Description 

This clause expands on the definition and summarizes the operation of the service (or service capability) in a generic 
form which does not constrain terminal or network design. It is intended to allow an understanding of the service (or 
service capability) without regard to implementation. It also includes any specific terminology used within the prose 
definition and description, and any qualifications. For basic services this clause details the applications which could 
utilize the service whilst for supplementary services this clause details their applicability to particular 
telecommunication services. 

4.2.3 Procedures 

The overall operation of the service (or service capability) in its various states is described in this clause. These 
procedures relate to all actions between the user(s) and the network during the period that the service (or service 
capability) is available. 
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4.2.3.1 Provision/withdrawal 



This clause describes the means by which the service (or service capabiHty) is made available by the service provider, 
e.g. it may be generally available to all customers, or only be available to those customers who have made a prior 
arrangement. 

4.2.3.2 Normal procedures 

The clauses under this heading describe the normal procedures for activation, deactivation, registration, invocation and 
operation for the service (or service capability) as appropriate. This clause describes only the successful outcome of 
each procedure, and the procedures which are executed as a result of such successful outcomes. The procedures are 
described in a time-based sequence of events. They describe the interactions of the users involved in the service (or 
service capability) with the service provider and with each other which lead to, and are elements of, the successful 
operation of the service (or service capability). 

4.2.3.2.1 Activation/deactivation/registration 

The procedures for activation, which is the operation of bringing the service into the "ready for invocation" state, and 
deactivation, which is the complementary action, are described in this clause. For some services (or service capability) 
there may be a specific user procedure to allow activation and deactivation as necessary, whilst for others the service (or 
service capability) is permanently activated on provision and thus no procedure is provided. 

Registration describes the procedures by which any specific information, necessary for the successful operation of the 
supplementary service, is given to the network. The need to register information with the network, e.g. a forwarding 
number, only applies to certain services (or service capabilities). 

4.2.3.2.2 Invocation and operation 

This clause describes the procedures for invocation, which is the action and conditions under which the service (or 
service capability) is brought into operation; in the case of some services (or service capabilities) this may only be on a 
particular call. It should be noted that although a service (or service capability) may be activated, it may not necessarily 
be invoked on all calls. (Invocation may take place either subsequent to or simultaneously with activation.) 

In the case of basic services this clause shall describe the events, perceived at the service access point, during the 
establishment, information transfer and clearing phases. 

Operation is the procedure which occurs once a service (or service capability) has been invoked. 

This description gives details of the significant actions of the network, treated in principle as a single entity, and the 
perception of the users involved in the service (or service capability). It includes details of the information exchanged 
between the network and relevant users and the indications given to each user, by the network, concerning the states of 
the service (or service capability). 

4.2.3.2.3 Interrogation/editing 

Interrogation is the facility which enables a served user to determine, from the service provider, the current status of a 
particular service. Whether this facility is provided for the service (or service capability) being described, and if so, the 
procedures that accompany it, are detailed in this clause. 

4.2.3.3 Exceptional procedures 

The clauses under this heading describe the exceptional procedures which result in an unsuccessful outcome of the 
service (or service capability). Included within this description are the details for such situations as invalid user action 
and the handling of certain network and interface conditions. For the case of basic services this includes the handling of 
such network conditions as congestion. 



£75/ 



9 ETSI TS 101 882-1 V4.1.1 (2003-09) 

4.2.4 Interaction with otiner services and service capabilities 

This clause shall describe all interactions of the service or service capability with other services or service capabilities 
insofar as they have been identified. 

For example, for some service or service capability pairs there is no interaction as the two are not permitted to be both 
in operation at the same time. For other pairs, one or both services (or service capabilities) may be modified whilst the 
pair are in operation simultaneously. 

4.2.5 Content of the dynamic definition 

The dynamic description of a service (or service capability) contains all the information that is sent and received by the 
user from activation/invocation of the service (or service capability) to completion of the service (or service capability). 
The information shall be presented in the form of an overall specification and description language (SDL) diagram an 
UML activity diagram. 

4.3 Content of the behavioural section 

4.3.1 Derivation of a functional model 

A functional model shall be derived for each service (or service capability) for which a meta-protocol is required. The 
functions required to provide the service (or service capability) are grouped into functional entities. The functional 
model is the aggregate of the functional entities and their relationships. 

4.3.2 Information flow diagrams 

The distribution of the functions needed to provide a service (or service capability) as defined by the functional model 
requires that interactions be defined between functional entities. Such an interaction is referred to as an "information 
flow" and shall have a name descriptive of the intent of the information flow. Information flow diagrams shall be 
created for normal operation and should be created as appropriate for exceptional operation. 

The semantic meaning and information content of each information flow shall be identified. The information content of 
each information flow shall be described using ASN.l. 

4.3.3 SDL/UML diagrams for functional entities 

The functions performed within a functional entity shall be identified and represented in the form of either a 
Specification and Description Language (SDL) diagram or a Unified Modelling Language (UML) diagram. 

The inputs and outputs of the SDL (UML) diagram are to and from the users as described in the requirements part and 
are information flows to and from other functional entities. 

SDL (UML) diagrams shall be defined for each functional entity based on the information flows defined for the normal 
behaviour of the service. The SDL diagrams shall also covers the exceptional behaviour. 

4.3.4 Functional Entity Actions 

The actions performed within a functional entity shall be represented as a list, or sequence, of functional entity actions 
(FEAs) in prose form. These form the basis for understanding the meaning of the information flows and provide a basis 
for the mapping activity. 
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5 Method of mapping to the meta-protocol 

5.1 Introduction 

As identified in clause 4. 1 the purpose of a meta-protocol is to serve as "the platform for candidate protocols to map to 
and in which the mapping identifies exactly how the requirements are met". 



5.2 Pre-analysis of the candidate 



In the meta-protocol development the resulting description is made without prejudice to the protocol used to implement 
the meta-protocol. This approach allows many protocols to be used to implement the service or service capability, 
however the ability of any candidate to meet the requirements of any meta-protocol has to be determined in advance. If 
a candidate cannot meet the requirements of any meta-protocol no mapping should be performed, however, the 
shortcomings in the candidate that prevent it from making a successful mapping should be identified in a separate report 
as the basis of a request to extend the functionality of the candidate sufficiently to allow the mapping to be made. 

5.2.1 Identify Protocol Entities (RE) of candidate 

In order to perform the mapping exercise the candidate has to explicitly identify the protocol entities of the candidate 
protocol. 

EXAMPLE: In SIP the protocol entities are described as the UAC, UAS, proxy server, registrar and redirect 
server. 

5.2.2 Identify Protocol Data Units of candidate 

In order to perform the mapping exercise the candidate has to explicitly identify the protocol data units of the candidate 
protocol. 

EXAMPLE 1 : In SIP the PDUs are not easy to identify. However, each method could be considered as a PDU 

type (although it is hard to evaluate the impact of the session description) and the header elements 
as the PDU data elements. 

EXAMPLE 2: A SIP INVITE PDU request has mandatory content of Call-id, Contact, Cseq, From, 
Max-forwards, To, Via. 

5.3 Mapping of RE to FE 

If many FEs map to a single PE the information flows between the encompassed FEs do not need to be mapped. 

5.3.1 Allocation of functional entities to protocol entities 

In this step, the functional entities and information flows identified in the meta-protocol are allocated to candidate 
specific types of physical locations, e.g. a PABX, an exchange, a gatekeeper, a server. Each allocation is called a 
scenario and is specific to the candidate protocol's capabilities. The relationship supported between two functional 
entities located in different physical locations must be realized within protocol(s) supported between those locations. 

The physical location applicable to the candidate shall also be mapped to the reference architecture described in 
TS 101 314 [1]. 

EXAMPLE: The QoS functional entity model is given in annex A. If we consider SIP we can map QFEl to the 
UAC and identify it as belonging to the originating terminal functional grouping. 
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Annex A (informative): 
Example 

The following example is drawn from the description of the End-to-End QoS Control model for TIPHON. 

A.1 Description 

A. 1.1 General description 

End-to-End QoS Signalling is used within a TIPHON network to ensure that a caller is provided with an end-to-end 
connection having at least the QoS class subscribed to or a lower QoS class if this is acceptable to the user. A QoS level 
may either be requested explicitly by the user on a call-by-call basis or may be predefined as part of the user's 
subscription. Additionally, the caller may be able to take specific actions if the QoS moves outside the accepted level 
during an established call. 

The user may use any of the following methods to request a specific end-to-end QoS at call establishment: 

By subscription: 



• 



The agreement between the user and the user's service provider identifies the QoS level to be requested 
for any call. The QoS level may be fixed or variable based upon such parameters as time-of-day and call 
destination. This method requires no signalling between the user and the service provider at call setup 
time. 



• 



By the use of a standardized TIPHON QoS Class: 
NOTE: And so forth outhning the essential considerations of the service from the viewpoint of the service user. 

A. 1.2 Procedures 

A.I .2.1 Provision and witindrawal 

End-to-End QoS Signalling shall be provided on a per-name, per application basis to all subscribers to the simple call 
within a TIPHON system. 

When establishing a call, a user shall be able to select at least one of the options identified in table A.l. 

Table A.l : QoS option 



Option 


Value 


QoS class 


- Predefined by user and service provider (TIPHON or non-TIPHON class) 

- TIPHON Best - QoS Class 3 (see note 1) 

- TIPHON High - QoS Class 2H (see note 1) 

- TIPHON Medium - QoS Class 2M (see note 1) 

- TIPHON Acceptable - OoS Class 2A (see note 1 ) 

- TIPHON Best effort - OoS Class 1 (see note 1 ) 

- Non-TIPHON QoS Class (see note 2) 


NOTE 1 : This value shall be as defined in TS 1 02 024-2 [6]. 

NOTE 2: This may be any value agreed between the user and the service provider to indicate a specific QoS 



A. 1.2. 2 Normal procedures 

A.1 .2.2.1 Activation, deactivation and interrogation 

QoS Signalling shall be permanently activated. 
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A.1 .2.2.2 Invocation and operation 



When establishing a simple call, the calling user (or an agent within the user's network) may request a TIPHON 
standardized QoS class or a non-standardized QoS class, to be applied to the call in order to achieve a required 
end-to-end QoS. 

If the end-to-end QoS requested by the calling user is available, communication using that QoS shall be established 
following the simple call procedures specified in TS 101 878 [4]. 

A. 1.2. 3 Exceptional procedures 
A.1 .2.3.1 Invocation and operation 

If it is not possible to offer the requested end-to-end QoS at call establishment, the calling user shall be informed and 
may take one of the following actions: 

• terminate the call attempt; 

• request a lower QoS; 

• proceed with the call at the QoS available between the caller and the called user. 

If, during an established call, the end-to-end QoS perceived by the calling user falls below an acceptable level the 
following practical options are available: 

• terminate the call; 

• continue with the call at the inferior QoS level. 

NOTE: These sections clearly describe the behaviour expected without worrying about the kind of entity that 
implements the behaviour. 

A.1 .3 Interactions with other TIPHON service capabilities 

This clause specifies interactions with other TIPHON services for which standards were available at the time of 
publication of the present document. 

A. 1 .3. 1 Registration service capabilities 
A.1 .3.1 .1 Terminal transport service registration 

No interaction. 

A. 1 .3. 1 .2 User service registration 

No interaction. 

NOTE: The QOS to be used for subsequent calls by the registered user may form part of the information supplied 
at registration. 



A.1 .3.2 Call connectivity service capabilities 
A.1 .3.2.1 Simple call establishment 

No interactions. 



£75/ 



13 ETSI TS 101 882-1 V4.1.1 (2003-09) 

A.1 .3.2.2 Calling user identity generation 

No interactions. 

NOTE: This carries on to describe the expected interactions for every service or service capabiHty already 
described in some (pubHshed) form. In doing this additional requirements are set for the behavioural 
modelling which will follow. 



A. 1.4 Interworking considerations 



When interworking with a Switched Circuit Network (SCN) where the only variable affecting QoS is the choice of 
bearer service, fixed QoS parameters shall be assumed based on the bearer service selected. 

NOTE: This section gives guidance to the developer. In this case as SCNs have QoS implicit in the bearer-service 
signalling may not be required. Clearly describe the behaviour expected without worrying about the kind 
of entity that implements the behaviour. 

A. 1.5 Overall behaviour 

Table A. 1 contains the dynamic description of End-to-End QoS Signalling using a Unified Modelling Language (UML) 
activity diagram. The activity diagram represents the behaviour of a TIPHON system in providing End-to-End QoS 
Signalling. 

NOTE: The syntax and semantics of UML diagrams are defined by the Object Management Group (OMG). 
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\/ 
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NOTE: The form of this diagram is up to the user but UIVIL and SDL are the most appropriate. It should summarize 
the normal and exceptional behaviour as simply as possible (i.e. without considering data too much). 

Figure A.I : Overall behaviour of End-to-End QoS Signalling at call establishment 
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A.2 Functional entity model and information flows 

A.2.1 Functional entity model 
A.2.1 .1 Description of model 

The functional model shall comprise the following QoS Functional Entities (QFE): 

• Calling User The application at the calling user's terminal which instigates the service request; 

• QFEl The service agent that processes the calling user's request for end-to-end QoS signalling; 

• QFE2 The originating QoS coordination function. This QFE is responsible for negotiating and 

establishing a particular QoS on behalf of the calling user; 

• QFE3 The terminating QoS coordination function. This QFE is responsible for establishing a 

particular QoS on behalf of the called user; 

• QFE4 The service agent that processes an incoming call to the called user; 

• QFE5 The QoS policy control function associated with the calling user's service provider; 

• QFE6 The transport coordination function serving the calling user; 

• QFE7 The transport coordination function serving the called user; 

• QFE8 An intervening QoS coordination function. This QFE is responsible for establishing a 

particular QoS within an intervening domain; 

• QFE9 An intervening transport coordination function; 

• Called User The application in the called user's terminal at which the service request is terminated. 
The following functional relationships shall exist between these QFEs: 

• ra between the Calling User and the Calling User's service agent (QFEl); 

• rb between the Calling User's service agent (QFEl) and the Calling User's QoS 

coordination function (QFE2); 

• re between QoS coordination functions in the originating side (QFE2) and an intervening 

QoS coordination function (QFES); 

• rd between an intervening QoS coordination function (QFES) and the Called User's QoS 

coordination function (QFE3); 

• re between the Called User's QoS coordination function (QFE3) and the Called User's 

service agent (QFE4); 

• rf between the Called User's service agent (QFE4) and the Called User; 

• rg between the Calling User's service agent (QFEl) and the QoS Policy Control function 

associated with the Calling User (QFES); 

• rh between the originating QoS coordination function (QFE2) and the originating transport 

coordination function (QFE6); 

• ri between an intervening QoS coordination function (QFES) and the transport 

coordination function associated with it (QFE9); 

• rj between the terminating QoS coordination function (QFE3) and the terminating 

transport coordination function (QFE7). 
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Figure A.2 shows the Functional Entities (QFE) and the relationships between them. 
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NOTE: This model represents a simple view of the essential functional elements required to implement the 
service. 

Figure A.2: End-to-end QoS signalling functional entity model 

A.2.1 .2 Description of functional entities 



A.2.1.2.1 



Calling user 



The Calling User functional entity acts on behalf of the human user to request the establishment of an end-to-end call 
with a specific QoS. 

A.2.1 .2.2 Calling user's service agent, QFE1 

On receipt of a QoS establishment request from the Calling User, QFEl determines whether current policy permits the 
requested QoS to be used with the call and either initiates a simple call establishment request towards the destination 
address or rejects the call request back to the calling user. 

NOTE: and so on for the remainder of the FEs. This description should act as justification for why the FE appears 
in the model. 



A.2. 2 Information flows 



A.2. 2.1 Definition of information flows 



A.2.2.1.1 Relationship ra 



A.2.2.1.1.1 



OrigQoSEstab 



OrigQoSEstab is a confirmed information flow that shall be sent across relationship ra from the calling user to QFEl 
to indicate a request for a new call establishment with a specific end-to-end QoS. Table A.2 lists the elements within the 
OrigQoSEstab information flow. 
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Table A.2: Content of OrigQoSEstab 



OrigQoSEstab 


Information element 


Value 


Request 


Response 


QoS Service Class 


- Predefined 
-TIPHON QoS class 
-3 Best 

-2H High 

- 2I\/I Medium 

- 2A Acceptable 

- 1 Best effort 

- Non-standardized QoS class 


M 




Called user ID 


TIPHON user name 


M 












Codec 


- List of possible codecs 

- Codec type 

- Frames per packet 


M 


(see notes 1 
and 2) 


Result 


- End-to-End QoS Established 

- with requested QoS 

- Rejection cause 

- Requested QoS not available 

- Called user unknown 

- No compatible codec available 

- Policy Rejection 




M 


NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the Result element is set to "End-to-End QoS Established". 



A. 2. 2.1 .2 Relationships rb, re, rd and re 



A.2.2. 1.2.1 



QoSEstab 



QoSEstab is a confirmed information flow that shall be sent across relationships rb, re, rd and re to indicate a request 
for the provision of a guaranteed end-to-end QoS for the associated TIPHON simple call. 

NOTE: The information flows belong to information relationships between FEs and should be grouped 

accordingly. A short text description of the purpose of the flow followed by a tabular grouping of the 
elements is appropriate. 

A.2. 2. 2 Information flow sequences 

A standard specifying TIPHON meta-protocols for end-to-end QoS Signalling shall provide signalling procedures in 
support of the information flow sequences specified below. In addition, signalling procedures should be provided to 
cover other sequences arising from error situations, interactions with simple call and interactions with other service 
capabilities. 

In the figures, end-to-end QoS Signalling information flows are represented by solid arrows. Within a column 
representing a QoS Signalling functional entity, the numbers refer to functional entity actions listed in the MSC 
diagrams. 

The following abbreviations are used: 



req 
resp 



request; 
response. 



A. 2. 2. 2.1 Normal operation 

Figure A.3 shows the information flows for the successful establishment of End-to-End QoS. 
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Calling 
User 



OrigQoSEstab.resflO^ 



QoSPolicy.resp 



QFE2 



1 c 



Reserve Timer 



-^ 



:\ r 



TRMConnecLreq 



Reserve Timer 



TRMReserue.req 



Called 
User 



Figure A.3: Information flows for successful QoS establishment 

The information flows in figure A.4 for successful QoS establishment can also be expressed in the form of a UML 
collaboration diagram as shown in figure A. 1 . 





r 


QFE5 


J 


7: QoSEstab.req 1 0: QoSEstab.req 


13: QoSEstab.req 




U: DeslQoSE stab, req 






^: QoS Pol icy. req 
1:OrigQoSEslab.req 


■>u 


3:QoSPolicy.resp 

4:QoSEstab.raq 




User 


> |— 


QFE1 


1 ^ 1 ore- 1 "* 1 orcn 1 -^ 1 or 


E3 


1 '' r 


QFE4 


1 > 


User 


< 1 


1 ^ 1 0"=^- 1 . 1 QFE8 1 ^ 1 QF 


1 < 1 


1 < 




26: OrigQoSEslab.resp 




35: QoSEstab.resp 

6: TRMReserve.resp 

24:TRMConnect.resp 


22: QoSEstab.resp 

9: TRMReserve.resp 
5:TRMReserve.req 

21:TRMConnect.resp 
23:TRMConnecl.req 


19: QoSEstab.resp 

8: TRMReserve.req 

12:TRMReserve.resp 

20:TRMConnect.req 

18:TRMConnect.resp 


4^ 


16: QoSEstab.resp 

:TRMReserve.req 

: TRMConnect.req 




15: DestQoSEstab.resp 






1 QFE6 1 1 QFE9 | | QFE7 


n 





Figure A.4: Successful QoS establishment shown in a collaboration diagram 

NOTE: The intention here is to place all of the information in the preceding sections into context. The normal 

approach is the MSC format although the UML collaboration diagram looks a bit more like the FE model 
presented earlier. Every attempt should be made to get the diagram onto a single page. 

A.2.3 QoS Functional entity actions 

Throughout the descriptions of QFE actions, the following conventions are used to identify information flows: 

• an information flow is referred to as a "request" at the QFE that sends it and as an "indication" at the QFE that 
receives it; 

• the corresponding confirmation is referred to as a "response" at the QFE that sends it and as a "confirmation" 
at the QFE that receives it. 

The following QFE actions shall occur at the points indicated in the information flow diagrams. 
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A.2.3.1 Actions of QFE1 



101: On request from the Calling User (OrigQoSEstab indication), determine transport parameters 

to be used, formulate a QoSPolicy request and send it to QFE5; 

102: Receive a positive QoSPolicy confirmation indicating that the call is permitted with the 

requested QoS, formulate a QoSEstab request and send it to QFE2; 

103: Receive a positive QoSEstab confirmation, formulate a positive OrigQoSEstab response and 

send it to the Calling User; 

104: Receive a negative QoSEstab confirmation, formulate a corresponding negative 

OrigQoSEstab response and send it to the Calling User; 

105: Receive a negative QoSPolicy confirmation, formulate a corresponding negative 

OrigQoSEstab response and send it to the Calling User; 

106: Receive a positive QoSPolicy confirmation indicating that the call is permitted but with an 

alternative QoS to that requested by the Calling User, formulate a QoSEstab request and send it 
to QFE2; 

107: Receive a positive QoSEstab confirmation, formulate a positive OrigQoSEstab response 

indicating that an alternative QoS to that requested has been used and send it to the Calling User. 

A.2.3.2 Actions of QFE2 

201: Receive a QoSEstab indication, formulate a TRMReserve request and send it to QFE6; 

202: Receive a positive TRMReserve confirmation, formulate a QoSEstab request and send it to 

QFE8; 

203: Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to 

QFE6. On receipt of a positive TRMConnect confirmation, send a positive QoSEstab response 
toQFEl; 

204: Receive a negative QoSEstab confirmation, send a TRMRelease request to QFE6 and send a 

negative QoSEstab response to QFEl; 

205 (not shown): Receive a positive QoSEstab confirmation, formulate a TRMConnect request and send it to 
QFE6. On receipt of a negative TRMConnect confirmation, formulate a negative QoSEstab 
response, send it to QFEl and stimulate the release of the TIPHON Simple Call towards the Called 
User. 

NOTE: And so on for each FE and each point on the MSCs where some FE action is identified. 

A.2.4 QoS Functional Entity beinaviour 

The behaviour specified in this subclause is intended to illustrate typical QFE behaviour in terms of information flows 
sent and received. 

The behaviour of each QFE is shown using the Specification and Description Language (SDL) defined in ITU-T 
Recommendation Z. 100 [7]. 

A.2.4. 1 Beinaviour of QFE1 

The behaviour of QFEl is shown in the SDL process diagram in A. 5, A.6, A.7 and A. 8. 
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PROCESS QFE1 



DCL 


K 

CallReqType, 


QoSRequest 


QoSResponse 


CallRespType, 


QoS Result 


OrigResult, 


PolicyParams 


PolicyReqType, 


Policy Result 


PohcyResult, 


QoSEstab 


QoSReqType, 


QoSEstabResp 


QoSRespType, 


QoSEstab Result QoSEstabResult, | 


SelectedCodec 


CodecList; | 



BuildPolicyRequest 



BuildOoSRequest 



DetermineTransportParameters 



Figure A.5: SDL process diagram for functional entity QFE1 (1 of 4) 



PROCESS QFE1 



o 



Orig_ 

QoSEstab 

(QoSRequest) 



?st)\ 



FROM Calling User 



Bultd_ 
PollcyRequest 



(QoSRequest, 
PolicyParams) 



QoSPollcy_ri 
(PolicyParams) 



JL 



VIA rg 



(WaitFor_ \ 
PolicyResponse I 



Figure A.6: SDL process diagram for functional entity QFE1 (2 of 4) 
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PROCESS QFE1 


































WaitFor_ 
PolicyResponse 


/ 
















QoSPollcy_rc / 
(Policy /- 
_Result} \ 




FRQM QFE5 








^^^"'^Ol 


cy^\ 












K 

Exceptional 
Behaviour 

-'/ 




ELSE 


.callAllowed 




Normal 
Behaviour 

"/ 








*\ Result ^^ 
































QoS_Result :- 
PolicyRejection 






Build_ 
QoSRequest 




(QoSRequest, 
QoSEstab) 




1 


















QoSResponse :^ 


— 


Add_Result_From 
(QoS_Result, QoSResponse) 




























Orig_ \ 

QoSEstab_rc y 
(QoSResponse)/ 


— 


VIA ra 




OoSEstab_ri 
(OoSEstab) 


> 


VIA rb 




Idle 






WaitFor_ 
EstabResponse 

























Figure A.7: SDL process diagram for functional entity QFE1 (3 of 4) 
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PROCESS QFE1 



/ WaitFor_ \ 
I EstabResponse I 



QoSEstab_rc 

(QoSEstab 

Resp) 



I 



■ FROM QFE2 



QoSEstab_ 
_Result := 



Exceptional 
Behaviour 



QoS_Result :- 

noCompatible_ 

Codec 




noCompatibleCodec ^^"''''^^-^ unknownuser 

"QoSEstab^ 
Result , 



QoS_Result := 
qoSNotAvailable 



QoS_Result := 
unknownUser 



^(r 



QoSresponse := 
origResultOnly 



Ensure OPTIONAL CodecList 

not included for encoding 



QoSResponse :-■ 



Add_Result_From 
(QoS_Result,QoSResponse) 



Orig_ 

OoSEstab_rc 

(QoSResponse" 



IZ 



Result_From (OoSEstabResp) 



qoSAvallable 



Normal 
Behaviour 



QoS_Result := 




requestedQoSEstablished 








QoSResponse := 




Add_Result_From 
(QoS_Result,QoSResponse) 








SelectedCodec := 




CodecList_From (QoSEstabResp) 








QoSResponse :^ 




Add CodecList From 
(SelectedCodec, QoSResponse) 


1 






Orig_ \ 

QoSEstab_rc } 
(QoSResponse^ 




VIA ra 


Idle 







Figure A.8: SDL process diagram for functional entity QFE1 (4 of 4) 

NOTE: And for each FE. The model should be built, validated and simulated. 
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Annex B (informative): 
Messaging capability meta-protocol 

B.1 Derivation from service capability 

The following example is derived from the service capabilities in the message class defined in TS 101 878 [4] and is 
used to illustrate the relationship between the service capabilities defined in TS 101 878 [4]. 

The class diagram from TS 101 878 [4] is replicated below (note that the normative source is of course TS 101 878 [4]). 



Message 



^contents : MessageRecord 
^^tatus : MessageStatus 
^^wner : Userldentifier 
^^ender : Userldentifier 
^^timeStamp : Date 



*«sc» create(newMessage : MessageRecord, addressee : Userldentifier) : Message 

^«sc» retrieve(calierlD : Useridentifier) 

*«sc» getStatus(calierlD : Useridentifier) 

♦«sc» setStatus(status : MessageStatus, calierlD : Useridentifier) 

^«sc» deiete(userlD : Userldentifier) 

*«return» message_Report() 

*«return» message_Resp() 

*«return» message_Retr() 

*«return» message„Status(status : MessageStatus) 

*«return» message_Resuit() 



«enumeration» 
MessageStatus 



^UnRead 
^Read 



«enumeration» 
MessageReturn 

^SuccessfuiOp 

^Faii_invaiidContents 

^Faii_Unl<nownAddressee 

^Faii_MessageUnRead 

^Faii_UnauthorizedUser 

^FaiiJnvaiidlD 



«data type» 
MessageRecord 



depositor : Userldentifier 
^messageTime : Date 



TextMessage 
^messageString : String 



MediaMessage 
^messageMediaBiock 



«data type» 
Userldentifier 

^identity : String 




0..n 



DialledMessage 
^ialledString : DialString 



«data type» 
DialString 



1..n 
«data type» 

DialUnit 

1 
2 
3 
4 
5 
6 
7 
8 
9 

# 



Figure B.I : Class diagram of message 
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B.2 SDL model 



From the message class in figure B.l a system in SDL is drawn as shown in figure B.2. This demonstrates a simple 
system containing a single block and two signal channels to the environment for each of the address and depositor (who 
are not modelled). 



UseTIPHON_MessageClassOperationStructures: 



^ 



system TIPHON_Message_Capabilities 



DepositorComms 
T-^ T^ 



(To_ 
User) 



(From_ 
user} 



^eP :Message_ a^d 
Processor 



AddresseeCom ms 
r^ 



(From_ 
User) 



(To_ 
User) 



Figure B.2: System diagram of message (page 1 of 3) 
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Use TiPHON_MessageClassOperationStructures 



^ 



system TIPHON_Message_Capabilities 








Message_ 
Processor 











Figure B.3: System diagram of message showing one block type (page 2 of 3) 
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Use TIPHON_MessageClassOperationStructures 



^ 



system TIPHON_Message_Capabilities 






signal msgCreate (CreateType) , |\ 
msgRetrieve (RetrieveType) , 
msgDelete (DeleteType) , 
msgSetStatus (SetStatusType) , 
msgGetStatus (GetStatusType) ; 

signal msgReport (ReportType) , 

msgResponse (ResponseType) , 
msgResult (ResultType) , 
msgReturn (ReturnType) , 
msgStatus (StatusType) ; 










signallist ToUser = msgResponse, |\ 
msgReturn, 
msgReport, 
msgResult, 
msgStatus; 

signallist FromUser = msgCreate, 

msgRetrieve, 
msgDelete, 
msgSetStatus, 
msgGetStatus; 











Figure B.4: System diagram of message showing signal lists (page 3 of 3) 

From the system diagram a single block type is defined containing, in this case, a single process. Using block types as 
opposed to blocks allows some degree of object orientation in the design. 
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dep 



lUserjl 

[(From 1 
I User) J 



|User)J 



block type MessageProcessor 



DepositorComm 



[(From 1 
I User) J 



^ Message_ 
Handler 



AddresseeComm 



(Frorn_ 
User) 



[(ToJ 
IUser)J 



^e 



add 



(From_ 
User) 



] 

Kl 

[User)J 



Figure B.5: Block type model of messaging 



As we delve deeper into the model we now define the process itself. In this model we also show a number of procedures 
required although for the purpose of standardization these procedures are not fully defined other than by their boundary 
conditions. 
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process MessageHandler 



CD 



del NewMessage 


CreateType, \ 


Time In 


DateTime, 


MsgID 


Msgldentif ier, 


RetrieveReq 


RetrieveType, 


MsgType 


ContType, 


Originator 


TIPHONUserName, 


MsgRep 


ReportType, 


Response 


ResponseType, 


Result 


ResultType, 


Message 


MsgContent, 


MessageReturn 


ReturnType, 


Deletelnfo 


DeleteType, 


Setlnfo 


SetStatusType, 


Getlnfo 


GetStatusType, 


Status 


MsgStatus, 


ReturnStatus 


StatusType; 



ValidateCreateRequest 



GetTimeStamp 



StoreMessage 



ValidateRetrieveRequest 



RetrieveMessage 



ValidateDeleteReques : 



ValidateGetStatusReques t 



DeleteMessage 



GetMessageStatus 



ValidateSetStatusReques t 



SetStatus 



Figure B.6: Process model of messaging (page 1 of 6) 
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process MessageHandler 



msgResult 
(Result) 



IL 



via DepositorComm 



I Idle I 



Idle 



msg Create 

(New_ 

Message) 



From Depositor 



ValidateCreateRequest 




{NewMessage, Result) 



GetTimeStamp 



(Time_ln) 



StoreMessage 



(NewMessage, Timejn, MsgID) 



MsgType : 



NewMessagelcontentslcategory 



Originator := 
NewMessageldepositor 



MsgReplmessagelD : 
MsgID 



MsgRepldepositor / 
Originator 



Msg Rep I category : 
MsgType 



MsgRepUimeStamp := 
Time_ln 



msg Report 
(MsgRep) 



> 



via AddresseeComm 



msgResult 
(Result) 



JL 



via DepositorComm 



Figure B.7: Process model of messaging (page 2 of 6) 
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process MessageHandler 



msg_ 

Retrieve 

(RetrieveReq^ 



32k 



■ From Addressee 



MsgID := 
RetrieveReq ! message I D 




ValidateRetrieveRequest — (RetrieveReq, Result) 



Result 

SuccessfulOP 



RetrieveMessage 



(MsgID, Message) 



MessageReturnlcontents := 
Message 



MessageReturnlmessagelD : 
MsgID 



MessageReturn!result := 
Result 



msg Return 
(Message_ 
Return) 



JZ 



via AddresseeComm 



Idle 



Figure B.8: Process model of messaging (page 3 of 6) 
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process MessageHandler 



msgDelete 
(Deletelnfo)" 



■ From Addressee 



MsgID := 
DeletelnfolmessagelD 



ValidateDeleteRequest — (Deletelnfo, Result) 




successfulOp 



DeleteMessage 



(MsgID) 



ResponselmessagelD : 
MsgID 



Responselresult := 
Result 



msgResponsi 
(Response) 



I 



via AddresseeComm 



Idle 



Figure B.9: Process model of messaging (page 4 of 6) 
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process MessageHandler 



msg_ 

SetStatus 

(Setlnto) 



I 



■ from Addressee 



MsgID := 
SetlnfolmessagelD 



ValidateSetStatusRequest 



else 




(Setlnfo, Result) 



Result 

successfulOp 



Status := 
Setlnfo!status 



SetStatus 



(MsglD, Status) 



Response!messagelD : 
MsgID 



Responselresult := 
Result 



msgResponsi 
(Response) 



JL 



via AddresseeComm 



Idle 



Figure B.10: Process model of messaging (page 5 of 6) 
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process MessageHandler 



I Idle I 



msg_ 

GetStatus 

(Getlnfo) 



I 



From Addressee 



MsgID := 
Getlnfo! message ID 



ValidateGetStatus Request 



else 




(Getlnfo, Result} 



Result 

successfulOp 



GetMessageStatus 



(MsgID, Status) 



ReturnStatus I status : 
Status 



ReturnStatuslmessagelD : 
MsgID 



ReturnStatuslresult / 
Result 



msgStatus 

(Return_ 

Status) 



via AddresseeComm 



Figure B.11 : Process model of messaging (page 6 of 6) 
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B.3 ASN.1 data definitions 

TIPHON-MessageClassOperationStructures DEFINITIONS ::= 

BEGIN 

— Type definitions for the contents of Service Capability Requests associated with the Message 
Class — 

— Message Create — 

CreateType ::= SEQUENCE { owner TIPHONUserName, 

depositor TIPHONUserName, 
contents MsgContent } 

— Message Retrieve — 

RetrieveType ::= SEQUENCE { messagelD Msgldentif ier, 

owner TIPHONUserName } 

— Message Delete — 

DeleteType ::= SEQUENCE { messagelD Msgldentif ier. 



TIPHONUserName 



— Set Message Status — 
SetStatusType ::= SEQUENCE 



messagelD Msgldentif ier, 
owner TIPHONUserName, 
status MsgStatus 



— Get Message Status — 

GetStatusType ::= SEQUENCE { messagelD Msgldentif ier, 

owner TIPHONUserName } 

Type definitions for the contents of responses associated with Message Service Capabilities 



— Report Incoming Message 
ReportType ::= SEQUENCE 



{ messagelD Msgldentif ier, 
depositor TIPHONUserName, 
category ContType, 
timeStamp DateTime 



— Signal Response — 

ResponseType ::= SEQUENCE { messagelD Msgldentif ier, 

result ResultType 



— Retrieved Message — 

ReturnType ::= SEQUENCE { result 



ResultType, 
messagelD Msgldentif ier, 
contents MsgContent 



OPTIONAL } 



— Retrieved Message Status 
StatusType ::= SEQUENCE 



{ result ResultType, 
messagelD Msgldentif ier, 
status MsgStatus 



OPTIONAL } 



— Miscellaneous data type definitions — 

ResultType ::= ENUMERATED { successfulOp, 

faillnvalidID, 
f aillnvalidContents, 
failUnknownAddressee, 
failMessageUnread, 
f ailUnauthorizedUser 

TIPHONUserName: := E164Number 

E164Number ::= NumericString (SIZE (1..15)) 



MsgContent 



SEQUENCE { category ContType, 

content CHOICE { null EmptyContent , 

dialled DialledContents, 

text TextContent, 

media MediaContent } 
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ContType : : 

EmptyContent ; ; 
DialledContents 
TextContent : : 
MediaContent : : 

Codec : : 



MsgStatus 



DateTime 



ENUMERATED { noMessage, 

dial ledMes sage, 

textMessage, 

mediaMessage 

NULL 

:= lASString (FROM ( " " . . " 9" | " * " I "#" ) ) (SIZE (1..100)) 

VisibleString (SIZE (1..1024)) 



SEQUENCE 


{ codec 


Codec, 






media 


BIT STRING 


ENUMERATED 


{ al016, 
celB, 
dVI4, 
g721, 
g722, 
g722-l, 
g723-l, 
g728, 
g729, 
gSM, 
h261, 
h263, 
iS01449, 
JPEG, 
116, 
IPC, 
mP2T, 
mPA, 
mPAA, 
mPV, 
nV, 
pCMA, 
pCMU, 
vDVI 






ENUMERATED 


{ unRead, 
read 






SEQUENCE 


{ year 


INTEGER 


(1 




month 


INTEGER 


(1 




day 


INTEGER 


(1 




hour 


INTEGER 


(0 




minute 


INTEGER 


(0 




second 


INTEGER 


(0 



Msgldentifier 



millisecond INTEGER (C 



VisibleString (SIZE (1..24)) 



.3000) 


.12), 


.31), 


.23), 


.59), 


.59), 


.999) 



END 
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